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DETAILED ACTION 

1 . This Action is in response to the Amendment for Application Number 1 0/601 ,237 
received on 6/14/2010. 

2. Claims 1 -29, 31 62 are presented for examination. 

3. Claim 30 has been cancelled. 

Claim Objections 

4. Claims 1,13, 24, 32, 33, 53 objected to because of the following informalities: 
Claims 1,13, 24, 32, 33, 53 recite the limitation, "said packet the according", which 
appears to include a grammatical error. Appropriate correction is required. 

Claim Rejections - 35 USC §112 

The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

5. Claims 1 -29, 31-32, 38, 41 , 46, 53, 54, 57 are rejected under 35 U.S.C. 1 1 2, 
second paragraph, as being indefinite for failing to particularly point out and distinctly 
claim the subject matter which applicant regards as the invention. 

6. Claims 1 recites the limitation, "associating an operation code with said first 
packet, wherein said operation code indicates a status of said first packet, including 
whether said packet is to be transferred to the host computer system for processing in 
accordance with said pres-selected protocol". Claim 1 then recites the limitation 
"processing, by the network interface, said packet the according to the TCP 
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connection." It is unclear what the purpose is of determining whether said packet is a 
candidate for transfer to the host that avoids processing in accordance with said pre- 
selected protocol, when the next limitation always processes the packet. It appears to 
defeat the entire purpose of determining whether to avoid processing or not, when the 
following limitation always processes the packet. Claims 1 3, 24, 53 are rejected for the 
same reasoning. 

7. Claim 32 recites the limitation, "processing, by the network interface, said packet 
the according to the TCP connection". The claim then follows with the limitation, "if the 
host computer system contains a plurality of processors such that a first of the 
processors is on the network interface and a second of the processors is on the host 
computer, identifying a processor of the first and second processors to process said 
packet". These limitations are unclear as it appears that the first mentioned limitation 
always requires the network interface to process the packet, and then in the second 
mentioned limitation, a determination is made as to whether the processor on the 
network interface does the processing or the processor on the host does the 
processing. It is unclear as to why this determination is being made, as it appears the 
processing has already been performed by the network interface before this 
determination. Claim 38 and 54 are rejected for the same reasoning. 



8. Claim 32 recites, "A method of transferring a packet received at a network 
interface to a host computer system". The amended limitation recites, "if the host 
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computer system contains a plurality of processors such that a first of the processors is 
on the network interface". The preamble differentiates the network interface and the 
host computer system as two separate elements. Therefore it is unclear how one of the 
host computer system's processors can be on the network interface. 

9. All dependent claims are also rejected herein as they include the limitations of 
their base claims. 

Claim Rejections - 35 USC §103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 1 02 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

1 0. Claims 1-12,1 4-1 7, 20-29, 31 , 42-44, 46-53, 55-56 are rejected under 35 U.S.C. 
103(a) as being unpatentable over Flanders et al. (US 6172980). 

1 1 . Regarding claims 1 , 24, 53, Flanders disclosed a method of transferring a packet 
to a computer system, wherein the packet is received at a communication device from a 
network (Flanders, col. 1, lines 39-41, a network router receiving and routing packets), 
comprising: 

parsing a header portion of a first packet received at a communication device to 
determine if said first packet conforms to a pre-selected protocol (Flanders, col. 3, lines 
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60-65, "RHP (Receive Header Processor) determines the protocol being used for the 
received data unit"; See also col. 6, lines 50-51); 

generating a flow key to identify a first communication flow that includes said first 
packet wherein said flow key includes a TCP connection for the communication flow 
(Flanders, col. 6, line 50 through col. 7, line 5, port information extracted from the 
received frame in order to classify packet according to flow ID, the information extracted 
from the packet used as a flow key to look the packet up, including IP protocol types, 
including TCP); 

routing the packets to their destination (Flanders, col. 1, lines 50-55, Flanders 
disclosed the router making forwarding decisions to route the packet, see also Abstract, 
"identifying a data unit to be routed by a router) 

associating an operation code with said first packet, wherein said operation code 
indicates a status of said first packet, including whether said packet is to be transferred 
to the hose computer system for processing in accordance with said pre=selected 
protocol (Flanders, col. 4, lines 22-35, 50-63 Flanders disclosed the RHP determining 
whether the packet is to be routed or bridged and performing protocol processing on the 
packet when it is to be routed based on bytes). 

Flanders further disclosed forwarding the packets for receipt by a downstream 
network device (Flanders, col. 9, lines 40-43). 

Flanders did not explicitly state transferring processing, by the network interface, 
said packet according to the TCP connection. 
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However, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made that since the router of Flanders clearly routes the packet to a 
network device, that the network device must perform the proper protocol processing on 
the packet in order to properly interpret the information from that packet. For example, 
using the very well known TCP/IP protocol, in order for two computers to successfully 
communicate via TCP/IP (Flanders, Fig. 6), both computers must protocol process the 
TCP/IP packets, which are clearly routed through the Internet, via routers such as the 
one described by Flanders. 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to interpret the routing of a packet to its destination to 
include that destination performing the proper protocol processing in order to obtain the 
predictable result of the destination device being able to successfully interpret that 
packet at the receiving end, thereby resulting in successful communication. 

Claim 24 includes a method with limitations that are substantially similar to the 
limitations of claim 1 , and is therefore rejected under the same rationale. Claim 53 
recites a computer readable storage medium storing instructions that perform the 
method of claim 1 . Therefore claims 24, 53 are rejected under the same rationale. 

1 2. Regarding claim 2, Flanders disclosed the limitations as described in claim 1 , 
including wherein said parsing comprises: copying a header portion of said first packet 
into a header memory; and examining said header portion according to a series of 
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parsing instructions; wherein said parsing instructions are configured to reflect a set of 
pre-selected communication protocols (col. 3, lines 45-65). 

1 3. Regarding claim 3, Flanders disclosed the limitations as described in claim 2. 
Flanders did not explicitly wherein said parsing instructions are updateable. However, it 
would have been obvious to any programmer or designer at the time the invention was 
made that any instructions carried out by a machine are updateable, as any software or 
hardware could be updated in order to accommodate the desires of the 
programmer/designer. 

14. Regarding claim 4, Flanders disclosed the limitations as described in claim 2, 
including copying a value from a field in a header of said header portion (Flanders, col. 
6, lines 50-56). 

1 5. Regarding claim 5, Flanders disclosed the limitations as described in claim 1 , 
including wherein said parsing comprises: extracting an identifier of a source of said first 
packet from said header portion; and extracting an identifier of a destination of said first 
packet from said header portion (Flanders, col. 3, lines 55-60). 

1 6. Regarding claim 6, Flanders disclosed the limitations as described in claim 5, 
including combining said source identifier and said destination identifier (Flanders, col. 
3, lines 55-60). 
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1 7. Regarding claim 7, Flanders disclosed the limitations as described in claim 1 , 
including 

wherein said generating comprises retrieving an identifier of a communication 
connection from said header portion (Flanders, col. 6, lines 49-60). 

1 8. Regarding claim 8, Flanders disclosed the limitations as described in claim 1 , 
including storing said first packet in a packet memory prior to said transferring 
(Flanders, col. 3, lines 45-55). 

1 9. Regarding claim 9, Flanders disclosed the limitations as described in claim 1 , 
including storing said flow key in a flow database, wherein said flow database is 
configured to facilitate management of said first communication flow (Flanders, col. 6, 
lines 50-65, "Flow Filtering Table"). 

20. Regarding claim 1 0, Flanders disclosed the limitations as described in claim 9, 
including associating a flow number with said first packet, wherein said flow number 
comprises an index of said flow key within said flow database (Flanders, col. 6, lines 50- 
65, "Flow ID"). 
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21 . Regarding claim 1 1 , Flanders disclosed the limitations as described in claim 1 0, 
including storing said flow number in a flow memory (Flanders, col. 6, lines 50-65, "Flow 
ID" is stored in the table). 

22. Regarding claim 12, Flanders disclosed the limitations as described in claim 9, 
including updating an entry in said flow database associated with said flow key when a 
second packet in said first communication flow is received (Flanders, col. 6, line 65 
through col. 7, line 15). 

23. Regarding claim 14, Flanders disclosed the limitations as described in claim 1 , 
including wherein said associating comprises: retrieving one or more header fields of 
said header portion; and analyzing said header fields to determine said status of said 
first packet (Flanders, col. 7, lines 1-15). 

24. Regarding claim 15, Flanders disclosed the limitations as described in claim 14, 
including wherein said analyzing comprises: determining whether said first packet 
includes a data portion; and if said first packet includes a data portion, determining 
whether said data portion exceeds a pre-determined size (Flanders, col. 4, lines 30-40). 

25. Regarding claim 16, Flanders disclosed the limitations as described in claim 14, 
including wherein said analyzing comprises determining whether said first packet was 
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received out of order in said first communication flow (Flanders, Fig. 6, TCP which is 
enabled for out of order packets). 

26. Regarding claim 1 7, Flanders disclosed the limitations as described in claim 1 , 
including storing said operation code in a control memory (Flanders, col. 7, lines 1-15). 

27. Regarding claim 20, Flanders disclosed the limitations as described in claim 1 , 
including determining whether a second packet received from said network is part of 
said first communication flow (col. 6, lines 50-65). 

28. Regarding claim 21 , Flanders disclosed the limitations as described in claim 20, 
including maintaining a packet memory configured to store one or more packets 
received from said network (col. 3, lines 45-55); 

maintaining a flow memory configured to store, for each of said one or more packets, an 
identifier of a communication flow comprising said packet (col. 6, lines 50-65); and 
searching said flow memory for a first identifier of said first communication flow (col. 6, 
lines 50-65). 

29. Regarding claim 22, Flanders disclosed the limitations as described in claim 21 , 
including wherein said first identifier comprises said flow key (col. 6, lines 50-65). 
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30. Regarding claim 23, Flanders disclosed the limitations as described in claim 21 , 
including wherein said first identifier comprises a flow number of said first packet, 
wherein said flow number is an index of said flow key within a flow database (col. 6, 
lines 50-65). 

31 . Regarding claim 25, Flanders disclosed the limitations as described in claim 24, 
including transferring said TCB from said host computer system to said communication 
device (col. 6, lines 50-65). 

32. Regarding claim 26, Flanders disclosed the limitations as described in claim 24, 
including receiving a second packet from a second communication flow; and processing 
said second packet by said communication device in accordance with said TCB (col. 6, 
lines 50-60, all packets received go through the same process if they are part of the 
same flow). 

33. Regarding claim 27, Flanders disclosed the limitations as described in claim 1 , 
including alerting said host computer system to the arrival of said first packet (col. 9, 
lines 40-45). 

34. Regarding claim 28, Flanders disclosed the limitations as described in claim 1 , 
including maintaining a packet memory configured to store packets received from said 
network (col. 3, lines 47-55). Flanders did not explicitly state randomly discarding a 
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packet if said packet memory contains a pre-determined level of traffic. However, it 
would have been obvious to one of ordinary skill in the art at the time the invention was 
made that buffered packets would be discarded as new packets arrive at the buffer, 
especially during the case that the buffer is completely filled, i.e. the packet memory 
contains a predetermined traffic level, in order to make room for new arriving packets 
and to allow the router to continue to operate properly. 

35. Regarding claim 29, Flanders disclosed the limitations as described in claim 1 , 
including wherein said parsing includes determining, by hardware of the communication 
device, a protocol of the header (col. 3, lines 50-60). Flanders also clearly disclosed the 
teaching of multiple protocol support. 

The teachings of Flanders does not limit itself to any particular type of protocol. 
This would have motivated one of ordinary skill in the art to implement the teachings of 
Flanders with any protocol well known in the art. 

The session layer is a well known layer from the OSI model. Therefore it would 
have been obvious to one of ordinary skill in the art at the time the invention was made 
to incorporate the session protocol within the teachings of Flanders since in order to 
make the teaching of Flanders scalable across well known protocols, thereby increasing 
its customer's desirability of use. 

36. Regarding claim 31 , Flanders disclosed the limitations as described in claim 1 , 
including wherein said communication device is a network interface (Fig. 1). 
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37. Regarding claims 42 and 44, Claim 42 includes an apparatus with a memory and 
modules to perform the limitations that are substantially similar to claim 1 and claim 44 
recites a computer system with limitations that are substantially to claims 1 . Claims 42 
and 44 further includes a "flow re-assembler configured to re-assemble a data portion of 
said first packet with a data portion of second packet in said communication flow and 
storing both packets in memory as well as a processor to process said packet and 
maintain a TCP connection for the flow. As shown in the rejection of claim 1 , Flanders 
disclosed a router performing these limitations. 

Flanders did not explicitly state flow re-assembler configured to re-assemble a 
data portion of said first packet with a data portion of second packet in said 
communication flow and storing both packets in memory of the downstream network 
device. 

However, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made that since the router of Flanders clearly routes the packets 
belonging to a particular flow to a network device, that the network device must perform 
the proper protocol processing on the packets in order to properly interpret the 
information from that packet, thereby requiring storing of the packet data and combining 
the data to properly interpret the flow. For example, using the very well known TCP/IP 
protocol, in order for two computers to successfully communicate via TCP/IP (Flanders, 
Fig. 6), both computers must protocol process the TCP/IP packets, which are clearly 
routed through the Internet, via routers such as the one described by Flanders. 



Application/Control Number: 1 0/601 ,237 Page 1 4 

Art Unit: 2443 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to interpret the routing of a packets to their destination to 
include that destination actually storing the packet data in order to perform the proper 
protocol processing in order to obtain the predictable result of the destination device 
being able to successfully interpret/batch that data from the packets at the receiving 
end, thereby resulting in successful communication. For example, the routing of a file 
that requires multiple packets to be sent in order to transmit the entire file across the 
network, which requires the receiving end to properly protocol process the packets that 
make up the file and re-assemble the data portions in order for communication of the file 
to properly occur. 

38. Regarding claim 43, Flanders disclosed the limitations as described in claim 42, 
including wherein said traffic classifier comprises: a parser configured to parse a header 
portion of said first packet; a flow database configured to store a flow key identifying 
said communication flow; and a flow database manager configured to manage said flow 
database; wherein said flow key is generated from an identifier of a source of said first 
packet and an identifier of a destination of said first packet (Flanders, Flanders, col. 6, 
line 50 through col. 7, line 5, port information extracted from the received frame in order 
to classify packet according to flow ID, the information extracted from the packet used 
as a flow key to look the packet up, see also col. 1 , lines 50-61 ). 
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39. Regarding claim 46, Flanders disclosed the limitations as described in claim 1 , 
wherein said operation code indicates whether the packet corresponds to Transport 
Control Protocol (TCP) (Flanders, col. 7, lines 10-15). 

40. Regarding claim 47, Flanders disclosed a device for receiving a packet from a 
network and transferring the packet to a host computer system, comprising: 

a parser configured to parse a header portion of a packet received from a 
network, wherein said parsing comprises: determining whether a header within said 
header portion conforms to one of a set of communication protocols (Flanders, col. 3, 
lines 60-65, "RHP (Receive Header Processor) determines the protocol being used for 
the received data unit"; See also col. 6, lines 50-51); and 

if said header conforms to one of said communication protocols, extracting information 
from said header portion to identify a communication flow to which said packet belongs 
(Flanders, col. 6, line 50 through col. 7, line 5, port information extracted from the 
received frame in order to classify packet according to flow ID, the information extracted 
from the packet used as a flow key to look the packet up); a flow memory configured to 
store a flow identifier for identifying said communication flow; a flow manager configured 
to assign an operation code to said packet, wherein said operation code: indicates a 
status of said packet; and indicates a manner of transferring said packet to the host 
computer system; a packet memory configured to store said packet wherein said device 
maintains a TCP connection for the communication flow (Flanders, col. 6, line 65 
through col. 7, line 15, in accordance with the received frame, a status word is set; see 



Application/Control Number: 1 0/601 ,237 Page 1 6 

Art Unit: 2443 

also, col. 4, lines 1 5-23. Flanders further disclosed forwarding the packets for receipt by 
a downstream network device; col. 9, lines 40-43) as well as a Flow filtering Table col. 
6, lines 50-67). 

Flanders did not explicitly state transferring said first packet to the disclosed 
device system for processing in accordance with said pre-selected protocol. 
However, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made that since the router of Flanders clearly routes the packet to a 
network device, that the network device must perform the proper protocol processing on 
the packet in order to properly interpret the information from that packet. For example, 
using the very well known TCP/IP protocol, in order for two computers to successfully 
communicate via TCP/IP (Flanders, Fig. 6), both computers must protocol process the 
TCP/IP packets, which are clearly routed through the Internet, via routers such as the 
one described by Flanders. 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to interpret the routing of a packet to its destination to 
include that destination performing the proper protocol processing in order to obtain the 
predictable result of the destination device being able to successfully interpret that 
packet at the receiving end, thereby resulting in successful communication. 

Flanders also did not explicitly state wherein said device is coupled to the host 
computer system by a bus. However it well known to one of ordinary skill that a bus is a 
device that is used to connect various computers/devices in a network. Since the router 
and end node is connected by a network, it would have been obvious to one of ordinary 
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skill in the art at the time the invention was made to couple these devices via a bus 
thereby making the system scalable towards already well known devices. 



41 . Regarding claim 48, Flanders disclosed the limitations as described in claim 47, 
wherein the device is a network interface (Flanders, Abstract). 

42. Regarding claim 49, Flanders disclosed the limitations as described in claim 47, 
said flow memory comprising a flow database configured to store a flow key, wherein 
said flow key is assembled from an identifier of a source of said packet and an identifier 
of a destination of said packet (Flanders, col. 6, line 50 through col. 7, line 5, port 
information extracted from the received frame in order to classify packet according to 
flow ID, the information extracted from the packet used as a flow key to look the packet 
up; col. 1, lines 50-67). 

43. Regarding claim 50, Flanders disclosed the limitations as described in claim 47, 
wherein said flow manager is further configured to update said flow memory as 
additional packets in said communication flow are received from the network (Flanders, 
col. 6, lines 50-67, col. 7, lines 1-5). 

44. Regarding claim 51 , Flanders disclosed the limitations as described in claim 47, 
said flow memory comprising a flow memory configured to store a flow number, wherein 
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said flow number comprises an index of said communication flow in a flow database 
(Flanders, col. 6, lines 50-67, col. 7, lines 1-5). 

45. Regarding claim 52, Flanders disclosed the limitations as described in claim 47, 
further comprising a control memory configured to store said operation code (Flanders, 
col. 7, lines 1-5). 

46. Regarding claim 55, Flanders disclosed the limitations as described in claim 47, 
wherein said transfer module is configured to transfer a data portion of said packet into 
one of a set of host memory areas in accordance with said operation code (Flanders, 
col. 7, lines 1-15). 

47. Regarding claim 56, Flanders disclosed the limitations as described in claim 47. 
Flanders did not explicitly state further comprising a packet batching module configured 
to determine whether said packet memory contains another packet in said 
communication flow. 

However, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made that since the router of Flanders clearly routes the packets 
belonging to a particular flow to a network device, that the network device must perform 
the proper protocol processing on the packets in order to properly interpret the 
information from that packet, thereby requiring storing of the packet data and combining 
the data to properly interpret the flow. For example, using the very well known TCP/IP 
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protocol, in order for two computers to successfully communicate via TCP/IP (Flanders, 
Fig. 6), both computers must protocol process the TCP/IP packets, which are clearly 
routed through the Internet, via routers such as the one described by Flanders. 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to interpret the routing of a packets to their destination to 
include that destination actually storing the packet data in order to perform the proper 
protocol processing in order to obtain the predictable result of the destination device 
being able to successfully interpret/batch that data from the packets at the receiving 
end, thereby resulting in successful communication. For example, the routing of a file 
that requires multiple packets to be sent in order to transmit the entire file across the 
network, which requires the receiving end to properly protocol process the packets that 
make up the file and re-assemble the data portions in order for communication of the file 
to properly occur. 

48. Claim 18 is rejected under 35 U.S.C. 103(a) as being unpatentable over Flanders 
et al. (US 6172980) in view of Lincoln (US 5991265). 

49. Regarding claim 1 8, Flanders disclosed the limitations as described in claim 1 , 
including processing of the header at a Receive Header Processor (Flanders, col. 1 , 
lines 50-60). 

Flanders did not explicitly state storing the data portion in a re-assembly storage 
area and one or more headers in a header storage area. 
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In an analogous art of packet processing, Lincoln disclosed packet processing in 
which the system transfers the cell payloads to a reassembly memory while processing 
the headers from control memory and then combining the header and payload before 
transferring the cell (Lincoln, col. 5, lines 30-40). As such, Lincoln provides evidence 
that it is well known to divide packets between header and payload in order to perform 
header processing of the packets. 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to utilize the splitting of packet header and payload as 
performed in the teachings of Lincoln in order to provide the system of Flanders in order 
to reduce the amount of data to be analyzed by the RHP in order to process the 
headers in a more efficient manner. 

50. Claims 32, 45, 54 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Flanders et al. (US 6172980) in view of Seno et al. (US 5590328). 

51 . Regarding claim 32, Flanders disclosed a method of transferring a packet 
received at a network interface to a host computer system, comprising: 

receiving a packet from a network, storing said packet in a packet memory and 
parsing a header portion of said packet; extracting a value stored in said header 
portion; identifying a communication flow comprising said packet, wherein said flow 
includes a TCP connection and a first MAC layer address(Flanders, col. 3, lines 60-65, 
"RHP (Receive Header Processor) determines the protocol being used for the received 
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data unit"; See also col. 6, lines 50-51 ; col. 6, line 50 through col. 7, line 5, and col 7, 
lines 15-20, port information extracted from the received frame in order to classify 
packet according to flow ID, the information extracted from the packet used as a flow 
key to look the packet up); 

determining whether a header in said header portion conforms to a pre-selected 
protocol (Flanders, col. 3, lines 60-65, "RHP (Receive Header Processor) determines 
the protocol being used for the received data unit"); 

determining whether a second packet in said packet memory is part of said 
communication flow (Flanders, col. 1, lines 39-40, Flanders disclosed performing the 
same for multiple received data units); and 

processing, by the network interface, said packet the according to the TCP 
connection (Flanders, col. 9, lines 40-43); 

if the host computer system contains a plurality of processors such that a first 
processor of the processors is on the network interface and a second of the processors 
is on the host computer, identifying a processor of the first and second processors to 
process said packet (Flanders, col. 4, lines 22-35, 50-63 Flanders disclosed the RHP 
determining whether the packet is to be routed or bridged and performing protocol 
processing on the packet when it is to be routed based on bytes, therefore determining 
whether the interface processes the packet or if it is sent to the end device for 
processing). 

Flanders further disclosed forwarding the packets for receipt by a downstream 
network device (Flanders, col. 9, lines 40-43) 
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Flanders did not explicitly state the step of storing said packet in a host memory 
area in the downstream network device. 

However, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made that since the router of Flanders clearly routes the packet to a 
network device, that the network device must perform the proper protocol processing on 
the packet in order to properly interpret the information from that packet, thereby 
requiring storing of the packet. For example, using the very well known TCP/IP 
protocol, in order for two computers to successfully communicate via TCP/IP (Flanders, 
Fig. 6), both computers must protocol process the TCP/IP packets, which are clearly 
routed through the Internet, via routers such as the one described by Flanders. 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to interpret the routing of a packet to its destination to 
include that destination actually storing the packet in order to perform the proper 
protocol processing in order to obtain the predictable result of the destination device 
being able to successfully interpret that packet at the receiving end, thereby resulting in 
successful communication. 



Application/Control Number: 1 0/601 ,237 Page 23 

Art Unit: 2443 

52. Regarding claim 45, Flanders disclosed the limitations as described in claim 42. 
Flanders also did not explicitly state wherein, comprising: a load distributor for 

identifying a first processor within the host computer system for processing said first 
packet and said second packet; wherein said load distributor identifies a second 
processor in the host computer system for processing a packet from a different 
communication flow. 

In an analogous art, Seno disclosed a protocol parallel processing device in 
which the device determines which processor, among which of multiple processors, to 
process the packet according to the communication (Seno, col. 2, lines 35-65). 

One of ordinary skill in the art would have been motivated to combine the 
teachings of Flanders and Seno since both teachings involve protocol processing of 
packets, and as such, both are within the same environment. 

Therefore it would have been obvious to one of ordinary skill in the art to 
incorporate the "multiple processors" teaching as disclosed by Seno into the teachings 
of Flanders in order to distribute communications across multiple processors, thereby 
improving efficiency of routing data through the router as the load is distributed among 
multiple processors, while also increasing throughput (Seno, col. 2, lines 15-35). 

53. Regarding claim 54, Flanders disclosed the limitations as described in claim 47. 
Flanders did not explicitly state wherein said host computer system is a multi-processor 
host computer system, further comprising a load distributor configured to select one of 
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said multiple processors for processing said packet in accordance with one of said 
communication protocols. 

In an analogous art, Seno disclosed a protocol parallel processing device in 
which the device determines which processor, among which of multiple processors, to 
process the packet according a protocol (Seno, col. 2, lines 35-65). 

One of ordinary skill in the art would have been motivated to combine the 
teachings of Flanders and Seno since both teachings involve protocol processing of 
packets, and as such, both are within the same environment. 

Therefore it would have been obvious to one of ordinary skill in the art to 
incorporate the "multiple processors" teaching as disclosed by Seno into the teachings 
of Flanders in order to distribute communications across multiple processors, thereby 
improving efficiency of routing data through the router as the load is distributed among 
multiple processors, while also increasing throughput (Seno, col. 2, lines 15-35). 

Allowable Subject Matter 
54. Claims 33-40 would be allowable if the objection to claim 33 is corrected. Claims 
58-62 are allowed. 

Response to Amendment 

Applicant's arguments and amendments filed on 63/15/201 1 have been carefully 
considered but they are not deemed fully persuasive. 

In view of Applicant's arguments over the newly amended independent claims, 
Applicant is respectfully requested to review the 1 12 2 nd rejections, provided above. 
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Applicant's arguments fail to comply with 37 CFR 1 .1 1 1 (b) because they amount 
to a general allegation that the claims define a patentable invention without specifically 
pointing out how the language of the claims patentably distinguishes them from the 
references. 

Applicant's has not clearly pointed out the patentable novelty which he or she 
thinks the claims present in view of the state of the art disclosed by the references cited. 
Applicant merely asserts that the language of the newly amended claims is not taught. 
Therefore, the Applicant has failed to rebut the Examiner's rejection of the claim with 
any persuasive analysis. Instead, Applicant grounds their argument on a conclusory 
assertion. This form of argument is wholly ineffective in demonstrating error in the 
Examiner's prima facie case to establish the patentability of the claims. See Ex parte 
Belinne, No. 2009-004693, slip op. at 7-8 (BPAI Aug 10, 2009)(informative), 

It is the Examiner's position that Applicant has not yet submitted claims drawn to 
limitations, which define the operation and apparatus of Applicant's disclosed invention 
in manner, which distinguishes over the prior art. 

Failure for Applicant to significantly narrow definition/scope of the claims and 
supply arguments commensurate in scope with the claims implies the Applicant intends 
broad interpretation be given to the claims. The Examiner has interpreted the claims 
with scope parallel to the Applicant in the response and reiterates the need for the 
Applicant to more clearly and distinctly define the claimed invention. 
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Conclusion 

Examiner's Note: Examiner has cited particular columns and line numbers in 
the references applied to the claims above for the convenience of the applicant. 
Although the specified citations are representative of the teachings of the art and are 
applied to specific limitations within the individual claim, other passages and figures 
may apply as well. It is respectfully requested from the applicant in preparing 
responses, to fully consider the references in entirety as potentially teaching all or part 
of the claimed invention, as well as the context of the passage as taught by the prior art 
or disclosed by the Examiner. 

In the case of amending the claimed invention, Applicant is respectfully 
requested to indicate the portion(s) of the specification which dictate(s) the structure 
relied on for proper interpretation and also to verify and ascertain the metes and bounds 
of the claimed invention. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to J. Bret Dennison whose telephone number is (571) 272- 
3910. The examiner can normally be reached on M-F 8:30am-5pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Tonia Dollinger can be reached on (571) 272-4170. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
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Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 



/J Bret Dennison/ 

Primary Examiner, Art Unit 2443 



